Welcome to a pyGSTi analysis report! This report is organized into tabs, each of which is accessible from the sidebar on the left. This Summary tab summarizes the most popular analyses and figures of merit. Much more detailed analysis is available on other tabs. If this report encapsulates multiple datasets, estimates, or gauges, then you can switch between those using the dropdown menus on the sidebar. For more information about how to use this report, click on the Help tab link to the left.
Model violation summary.This figure is about goodness-of-fit. It indicates how well each of the estimates contained in this report fits its corresponding data. PyGSTi finds the maximum value of the loglikelihood (-2\log\mathrm{Pr(data|gateset)}), and compares it to what we expect to see if the data were generated by a Markovian gateset. In this plot, each bar or box shows by how many standard deviations the actual log-likelihood exceeds its expected value. Expected values and standard deviations are derived from \chi^2 theory. Low values indicate better fits (less model violation).
Model violation per iteration.This figure is about goodness-of-fit. This plot shows how well this estimate fits the data. PyGSTi finds the maximum value of the loglikelihood (-2\log\mathrm{Pr(data|gateset)}), and compares it to what we expect to see if the data were generated by a Markovian gateset. In this plot, each bar shows by how many standard deviations the actual log-likelihood exceeds its expected value. Expected values and standard deviations are derived from \chi^2 theory. On the horizontal axis, L indexes different ML estimates based on datasets including only circuits of length up to L. Low values indicate better fits (less model violation). Each bar is colored according to the star rating shown in the Model Violation tab.
Histogram of per-circuit model violation.This figure is about goodness-of-fit. When the estimate doesn't fit the data perfectly, we can quantify how well it fails to predict each individual circuit in the dataset, using the excess loglikelihood (-2\log\mathrm{Pr}(\mathrm{data}|\mathrm{gateset})) above and beyond the minimum value (-2 \log \mathrm{Pr}(\mathrm{data}|\mathrm{observed\ frequencies})). This plot shows a histogram of the those values for all the circuits in the dataset. Ideally, they should have the \chi^2 distribution shown by the solid line. Red indicates data that are inconsistent with the model at the 0.95 confidence level, as shown in more detail in the Model Violation tab.
Comparison of estimated gates to targets.This table is about gate error metrics (fidelity). The metrics in this table compare the estimated gates to their ideal counterparts, and can generally be interpreted as some kind of error rate (per gate use). Entanglement (process) fidelity and 1/2-diamond norm are the best known of these; they are the same for purely stochastic errors, but coherent errors contribute much more to diamond norm. 1/2-trace-distance is a proxy for diamond norm that doesn't require cvxPy to be installed. The Eigenvalue metrics are gauge-invariant versions of fidelity and diamond-norm that only depend on the gate itself (not its relationship to other gates). Hovering the pointer over a heading will pop up a description.
Gate
Entanglement Infidelity
1/2 Trace Distance
1/2 Diamond-Dist
Eigenvalue Ent. Infidelity
Eigenvalue 1/2 Diamond-Dist
[]
-0.000179
0.000767
--
-0.000179
0.000566
Gxpi2:0
-0.000255
0.045137
--
-0.000218
0.000305
Gypi2:0
-0.00026
0.046994
--
-0.000201
0.000588
Gate
Entanglement Infidelity
1/2 Trace Distance
1/2 Diamond-Dist
Eigenvalue Ent. Infidelity
Eigenvalue 1/2 Diamond-Dist
[]
0.000144
0.00046
--
0.000144
0.000593
Gxpi2:0
5×10-8
0.000213
--
1×10-8
0.000151
Gypi2:0
0.000184
0.00046
--
0.000184
0.000464
Gate
Entanglement Infidelity
1/2 Trace Distance
1/2 Diamond-Dist
Eigenvalue Ent. Infidelity
Eigenvalue 1/2 Diamond-Dist
[]
0
0
--
0
0
Gxpi2:0
0
0
--
0
0
Gypi2:0
0
0
--
0
0
Model Violation Analysis
The plots and tables on this tab summarize how well the GST estimate actually fits the data. Although they may be less familiar to you than, say, process fidelity, these analyses are essential to understanding the GST estimate, and how much to trust it! Real qubit systems often display behavior that isn't consistent with modeling each gate as a stationary CPTP map. When pyGSTi tries to fit such data to its model (a single gateset), this "non-Markovianity" manifests as model violation. This tab provides several views of the model violation observed for this fit, ranging from the coarse-grained (total violation) to hyper-detailed (per-circuit violation). More observed model violation ⇒ the error metrics on other tabs should be trusted less.
Model violation summary.This plot summarizes how well GST was able to fit the data -- or subsets of it -- to a gateset. Bars indicate the difference between the actual and expected log-likelihood values, and are given in units of standard deviations of the appropriate \chi^2 distribution. Each bar corresponds to a subset of the data including only circuits of length up to \sim L; the rightmost bar corresponds to the full dataset. Low values are better (less model violation), and bars are colored according to the star rating found in a later table detailing the overall model violation.
Detailed overall model violation. This table provides a detailed look at how the observed model violation -- defined by how badly the GST model fits the data -- evolves as more and more of the data are incorporated into the fit. PyGSTi fits the data iteratively, starting by just fitting data from the shortest circuits (L=1), and then adding longer and longer sequences. Each subset of the data, defined by its maximum sequence length L, yields an independent fit that is analyzed here. The key quantity is the difference between the observed and expected maximum loglikelihood (\log(\mathcal{L})). If the model fits, then 2\Delta\log(\mathcal{L}) should be a \chi^2_k random variable, where k (the degrees of freedom) is the difference between N_S (the number of independent data points) and N_p (the number of model parameters). So 2\Delta\log(\mathcal{L}) should lie in [k-\sqrt{2k},k+\sqrt{2k}], and N_\sigma = (2\Delta\log(\mathcal{L})-k)/\sqrt{2k} quantifies how many standard deviations it falls above the mean (a p-value can be straightforwardly derived from N_\sigma). The rating from 1 to 5 stars gives a very crude indication of goodness of fit. Heading tool tips provide descriptions of each column's value.
L
2Δ(log L)
k
2Δ(log L)-k
√2k
Nsigma
Ns
Np
Rating
1
101.1576
61
40.15755
11.04536
3.64
92
31
★★★★
2
182.0049
137
45.00486
16.55295
2.72
168
31
★★★★
4
307.8997
254
53.8997
22.53886
2.39
285
31
★★★★
8
458.0245
417
41.02451
28.87906
1.42
448
31
★★★★★
16
654.6271
585
69.62714
34.20526
2.04
616
31
★★★★
32
799.9468
753
46.94683
38.80722
1.21
784
31
★★★★★
L
2Δ(log L)
k
2Δ(log L)-k
√2k
Nsigma
Ns
Np
Rating
1
105.1894
65
40.1894
11.40175
3.52
92
27
★★★★
2
184.713
141
43.71305
16.79286
2.6
168
27
★★★★
4
308.898
258
50.89796
22.71563
2.24
285
27
★★★★
8
461.6532
421
40.65323
29.01724
1.4
448
27
★★★★★
16
657.7668
589
68.76678
34.322
2
616
27
★★★★
32
816.6306
757
59.63062
38.91015
1.53
784
27
★★★★★
L
2Δ(log L)
k
2Δ(log L)-k
√2k
Nsigma
Ns
Np
Rating
1
563288.3
48
563240.3
9.797959
6×104
92
44
★
2
1×106
124
1×106
15.74802
7×104
168
44
★
4
2×106
241
2×106
21.9545
8×104
285
44
★
8
3×106
404
3×106
28.42534
1×105
448
44
★
16
4×106
572
4×106
33.82307
1×105
616
44
★
32
5×106
740
5×106
38.47077
1×105
784
44
★
Per-circuit model violation vs. circuit lengthThe fit's total 2\Delta\log(\mathcal{L}) is a sum over all N_s circuits used for GST. This plot shows 2\Delta\log(\mathcal{L}) for each individual circuit, plotted against that circuit's length (on the X axis). Certain forms of non-Markovian noise, like slow drift, produce a characteristic linear relationship. Note that the length plotted here is the actual length of the circuit, not its nominal L.
Model violation for each individual circuit
This tab presents the second of two statistical tests available to detect that a dataset violates pyGSTi's Markovian gateset model. The first is based on the aggregate loglikelihood score presented elsewhere. This tab shows the individual loglikelihood scores for each circuit in the dataset. Each circuit is represented by a colored box, whose color indicates how badly this estimate (model) failed to predict the observed outcome frequencies of that circuit. Light gray indicates consistency with the model, dark gray indicates possible -- but statistically insignificant -- inconsistency, and red squares indicate circuits whose outcomes are inconsistent with the model at the family-wise 95 percent confidence level. In other words, if data are generated by a Markovian gateset, then with 95%% probability every box will be gray. Even a single red square thus represents a clear detection of model violation. When many squares are red, their pattern can provide useful diagnostic clues to what kind of non-Markovian noise is present.
Per-sequence model violation box plot. This plot shows the 2\Delta\log(\mathcal{L}) contribution for each individual circuit in the dataset. Each box represents a single gate sequence, and its color indicates whether GST was able to fit the corresponding frequency well. Shades of white/gray indicate typical (within the expected) values. Red squares represent statistically significant evidence for model violation (non-Markovianity), and the probabilty that any red squares appear is 5% when the data really are Markovian. Each square block of pixels (plaquette) corresponds to a particular germ-power "base sequence", and each pixel within a block corresponds to a specific "fiducial pair" -- i.e., choice of pre- and post-fiducial sequences. The base sequences are arranged by germ (varying from row to row), and by power/length (varying from column to column). Hovering over a colored box will pop up the exact circuit to which it corresponds, the observed frequencies, and the corresponding probabilities predicted by the GST estimate of the gateset. The slider below the figure permits switching between different estimates, labeled by L, which were obtained from subsets of the data that included only base sequences of length up to L.
Per-sequence total variational distance box plot. This plot shows the total variational distance (\frac{1}{2}\sum_i|p_i-f_i|) contribution for each individual circuit in the dataset. Each box represents a single gate sequence, and its color indicates how well the observed frequency matches the probability generated by GST's best-estimate gate set. Each square block of pixels (plaquette) corresponds to a particular germ-power "base sequence", and each pixel within a block corresponds to a specific "fiducial pair" -- i.e., choice of pre- and post-fiducial sequences. The base sequences are arranged by germ (varying from row to row), and by power/length (varying from column to column). Hovering over a colored box will pop up the exact circuit to which it corresponds, the observed frequencies, and the corresponding probabilities predicted by the GST estimate of the gateset. The slider below the figure permits switching between different estimates, labeled by L, which were obtained from subsets of the data that included only base sequences of length up to L.
Gauge Invariant Error Metrics
GST can estimate gates up to an overall gauge. PyGSTi tries to find a good gauge in which to report process matrices and gauge-variant metrics like fidelity -- but sometimes this goes wrong. The most reliable error metrics and gate properties are gauge-invariant ones, and these are listed on this tab.
RB error metricsThis table shows estimates for the error rate that would be obtained using two different Randomized Benchmarking (RB) protocols . The Clifford RB number corresponds to the most standard form of RB, Clifford RB (CRB), where random Clifford gate sequences are performed. This number is dependent on how the Clifford operations are compiled into the primitive gates, and so if you didn't specify a Clifford compilation and pygsti couldn't deduce one, this quantity will be absent. Note that this is the error rate per-Clifford; it has not been rescaled to a per-primitive error rate. The primitive RB number corresponds to performing RB on random sequences of the primitive gates, rather than the Cliffords, which is known as Direct RB (DRB). DRB allows for sampling layers of primitives according to a general probability distribution over the primitive gates; the number reported here corresponds to uniformly sampling the primitive gates. This number does not require any compilation table and is always be computed by pyGSTi. Two caveats regarding these RB numbers: 1) The primitive RB number is not meaningful for arbitrary gate sets; if the gate set generates the Clifford group or it is a universal gate set then it is definitely meaningful, modulo the second caveat. 2) These predicted RB numbers rely on a perturbative technique, and if the estimated gates are far from their ideal counterparts the predicted numbers may be very inaccurate (and the empirical RB error rate itself may even be ill-defined: the RB decay could be non-exponential). For both of these RB protocols there is also more than one definition of the RB number, as a function of the p obtained from fitting RB data to A + Bp^m. Here we use the definition r = (4^n - 1)(1-p)/4^n for an n-qubit gate set, which means that r = entanglement infidelity = 1/2 diamond distance if there are uniform depolarizing errors on all the gates (where these two quantities are w.r.t. the gate set benchmarked, so the Clifford gates for CRB and the primitive gates for DRB). For more general errors, these first two quantities will often be roughly equal, although that is not guaranteed. Note that these numbers should not be directly compared to RB numbers derived using the commonly-used alternative formula r = (2^n - 1)(1-p)/2^n (which is related to average gate infidelity, rather than entanglement infidelity).
Metric
Value
Predicted primitive RB number
-1
Predicted Clifford RB number
-1
Metric
Value
Predicted primitive RB number
-1
Predicted Clifford RB number
-1
Metric
Value
Predicted primitive RB number
-1
Predicted Clifford RB number
-1
SPAM probabilities This table shows estimated SPAM probabilities for each measurement outcome. These are computed as \mathrm{Tr}[\rho E_i], where \rho is an estimated initial state (often labelled \rho_0), and \{E_i\} is the estimated n-outcome POVM. The symbol E_C denotes the nth POVM effect, which is not allowed to vary freely but is defined by subtracting the sum of the other effects (which are freely varied) from the identity.
0
1
Target ρ0
1
0
Estimated ρ0
0.141889
0.858111
0
1
Target ρ0
1
0
Estimated ρ0
0.15727
0.84273
0
1
Target ρ0
1
0
Estimated ρ0
1
0
Gram matrix spectrum.The GST Gram matrix is not a standard error metric, but it is gauge-invariant and critical to the GST process. It provides some insight into generalized SPAM. It is the (estimated) matrix of inner products between all the input states prepared by the various preparation fiducials, and all the measured effects prepared by the various measurement fiducials. LGST involves inverting the Gram matrix, so it needs to be full rank. In the plot, each pair of bars shows the nth eigenvalues of the estimated Gram matrix and the Gram matrix predicted by the ideal targets (respectively). Larger eigenvalues indicate better sensitivity, and the number of non-zero values indicates the dimension of the state (density matrix) space being probed (e.g., for a single qubit, the Gram matrix should have 4 O(1) eigenvalues).
Spectral error metrics between estimated gates and ideal targetsThis table presents a variety of gauge-invariant quantities that quantify the distance or discrepancy between (1) an estimated gate, and (2) the ideal corresponding target operation. Each of these error metrics depends only on a specific gate's spectrum (eigenvalues), which are gauge-invariant and non-relational (i.e., they pertain to a single gate). Hovering over a column header will pop up a mathematical description of the corresponding metric.
Gate
Eigenvalue Ent. Infidelity
Eigenvalue Avg. Gate Infidelity
Eigenvalue Non-U. Ent. Infidelity
Eigenvalue Non-U. Avg. Gate Infidelity
Eigenvalue 1/2 Diamond-Dist
Eigenvalue Non-U. 1/2 Diamond-Dist
[]
-0.000179
-0.00012
-0.00018
-0.00012
0.000566
0.000566
Gxpi2:0
-0.000218
-0.000146
-0.000225
-0.00015
0.000305
0.000238
Gypi2:0
-0.000201
-0.000134
-0.000277
-0.000185
0.000588
0.000459
Gate
Eigenvalue Ent. Infidelity
Eigenvalue Avg. Gate Infidelity
Eigenvalue Non-U. Ent. Infidelity
Eigenvalue Non-U. Avg. Gate Infidelity
Eigenvalue 1/2 Diamond-Dist
Eigenvalue Non-U. 1/2 Diamond-Dist
[]
0.000144
0.000096
0.000144
0.000096
0.000593
0.00016
Gxpi2:0
1×10-8
7×10-9
0
0
0.000151
0
Gypi2:0
0.000184
0.000123
0.000184
0.000123
0.000464
0.000271
Gate
Eigenvalue Ent. Infidelity
Eigenvalue Avg. Gate Infidelity
Eigenvalue Non-U. Ent. Infidelity
Eigenvalue Non-U. Avg. Gate Infidelity
Eigenvalue 1/2 Diamond-Dist
Eigenvalue Non-U. 1/2 Diamond-Dist
[]
0
0
0
0
0
0
Gxpi2:0
0
0
0
0
0
0
Gypi2:0
0
0
0
0
0
0
Single metric comparison.TODO: caption
Eigenvalue Ent. Infidelity
Gate
TP
CPTP
Target
[]
-0.000179
0.000144
0
Gxpi2:0
-0.000218
1×10-8
0
Gypi2:0
-0.000201
0.000184
0
Eigenvalue Avg. Gate Infidelity
Gate
TP
CPTP
Target
[]
-0.00012
0.000096
0
Gxpi2:0
-0.000146
7×10-9
0
Gypi2:0
-0.000134
0.000123
0
Eigenvalue Non-U. Ent. Infidelity
Gate
TP
CPTP
Target
[]
-0.00018
0.000144
0
Gxpi2:0
-0.000291
0
0
Gypi2:0
-0.00032
0.000184
0
Eigenvalue Non-U. Avg. Gate Infidelity
Gate
TP
CPTP
Target
[]
-0.00012
0.000096
0
Gxpi2:0
-0.000194
0
0
Gypi2:0
-0.000213
0.000123
0
Eigenvalue 1/2 Diamond-Dist
Gate
TP
CPTP
Target
[]
0.000566
0.000593
0
Gxpi2:0
0.000305
0.000151
0
Gypi2:0
0.000588
0.000464
0
Eigenvalue Non-U. 1/2 Diamond-Dist
Gate
TP
CPTP
Target
[]
0.000566
0.00016
0
Gxpi2:0
0.000238
0
0
Gypi2:0
0.000459
0.000271
0
Gauge-robust gate metrics. This table gives gauge-robust metrics indicating the intrinsic errors on a gate due to its eigenvalues not being perfect (the diagonal elements) and the relational errors between pairs of gates, due to having imperfect eigenspaces.
[]
Gxpi2:0
Gypi2:0
[]
-0.000179
-0.000036
-0.000059
Gxpi2:0
--
-0.000218
-0.110716
Gypi2:0
--
--
-0.000201
[]
Gxpi2:0
Gypi2:0
[]
-0.00012
-0.000024
-0.000039
Gxpi2:0
--
-0.000146
-0.073811
Gypi2:0
--
--
-0.000134
[]
Gxpi2:0
Gypi2:0
[]
0.000777
0
0
Gxpi2:0
--
0.001049
0.000735
Gypi2:0
--
--
0.001153
[]
Gxpi2:0
Gypi2:0
[]
--
--
--
Gxpi2:0
--
--
--
Gypi2:0
--
--
--
[]
Gxpi2:0
Gypi2:0
[]
-0.00018
-0.000072
-0.000119
Gxpi2:0
--
-0.000219
-0.000006
Gypi2:0
--
--
-0.000201
[]
Gxpi2:0
Gypi2:0
[]
-0.00012
-0.000048
-0.000079
Gxpi2:0
--
-0.000146
-0.000004
Gypi2:0
--
--
-0.000134
[]
Gxpi2:0
Gypi2:0
[]
0.001667
0
0
Gxpi2:0
--
0.000636
0.011854
Gypi2:0
--
--
0.001467
[]
Gxpi2:0
Gypi2:0
[]
0.000144
0
0
Gxpi2:0
--
1×10-8
1×10-7
Gypi2:0
--
--
0.000184
[]
Gxpi2:0
Gypi2:0
[]
0.000096
0
0
Gxpi2:0
--
7×10-9
9×10-8
Gypi2:0
--
--
0.000123
[]
Gxpi2:0
Gypi2:0
[]
0.00046
0
0
Gxpi2:0
--
0.000101
0.00036
Gypi2:0
--
--
0.000429
[]
Gxpi2:0
Gypi2:0
[]
--
--
--
Gxpi2:0
--
--
--
Gypi2:0
--
--
--
[]
Gxpi2:0
Gypi2:0
[]
0.000144
0
0
Gxpi2:0
--
0
0
Gypi2:0
--
--
0.000184
[]
Gxpi2:0
Gypi2:0
[]
0.000096
0
0
Gxpi2:0
--
0
0
Gypi2:0
--
--
0.000123
[]
Gxpi2:0
Gypi2:0
[]
0.001185
0
0
Gxpi2:0
--
0.000285
0.001064
Gypi2:0
--
--
0.001012
[]
Gxpi2:0
Gypi2:0
[]
0
0
0
Gxpi2:0
--
0
0
Gypi2:0
--
--
0
[]
Gxpi2:0
Gypi2:0
[]
0
0
0
Gxpi2:0
--
0
0
Gypi2:0
--
--
0
[]
Gxpi2:0
Gypi2:0
[]
0
0
0
Gxpi2:0
--
0
0
Gypi2:0
--
--
0
[]
Gxpi2:0
Gypi2:0
[]
--
--
--
Gxpi2:0
--
--
--
Gypi2:0
--
--
--
[]
Gxpi2:0
Gypi2:0
[]
0
0
0
Gxpi2:0
--
0
0
Gypi2:0
--
--
0
[]
Gxpi2:0
Gypi2:0
[]
0
0
0
Gxpi2:0
--
0
0
Gypi2:0
--
--
0
[]
Gxpi2:0
Gypi2:0
[]
0
0
0
Gxpi2:0
--
0
0
Gypi2:0
--
--
0
Eigenvalues of estimated gates. This table lists the spectrum of each estimated gate. It also breaks out the real and imaginary parts of each eigenvalue, and it compares the estimated eigenvalues to those of the ideal target gates in several useful ways. To do these comparisons, each estimated eigenvalue needs to be matched up with a target eigenvalue, and pyGSTi does this independently for each metric by computing a minimum-weight matching based on that metric. Hovering over a column header will pop up a mathematical description of the corresponding metric.
Gauge-robust gate set. This table gives a first-order gauge-invariant description of a gate set by decomposing each gate G as G = F^{-1} M G_0 F where M commutes with G_0 and F = exp(r) where r is zero on the diagonal blocks corresponding to the degenerate eigenvalues of G_0.
Gate
M - I
FinvF([]) - I
FinvF(Gxpi2:0) - I
FinvF(Gypi2:0) - I
[]
0
Gxpi2:0
0
Gypi2:0
0
Gate
M - I
FinvF([]) - I
FinvF(Gxpi2:0) - I
FinvF(Gypi2:0) - I
[]
0
Gxpi2:0
0
Gypi2:0
0
Gate
M - I
FinvF([]) - I
FinvF(Gxpi2:0) - I
FinvF(Gypi2:0) - I
[]
0
Gxpi2:0
0
Gypi2:0
0
Gauge Invariant Error Metrics applied to germ sequences
All of the per-gate gauge-invariant metrics of the previous tab are functions of each gate's spectrum and do not account for how the gate relates to other gates. In an attempt to extract some of that information in a gauge-invariant way, this tab looks at the spectra of the germ-sequences. Each germ amplifies (i.e. has eigenvalues which correspond to) certain directions in gate-set space. Some of these directions describe how the single gates relate to one another, and, if an amplificationally complete set of germs was used, every direction is amplified by at least one germ. This implies that the (gauge-invariant) spectra of the germs should constitute a full description of the gate set. This tab compares each germ-spectrum to the spectrum of that germ if it were generated using the set eigenspace-projected gates obtained by placing each gate's GST-estimated eigenvalues within eigenbasis of the ideal target gate.
Discrepancy between germs and spectral gates This table requires some explaining. It tries to answer the following question: "Is it plausible that each gate has only spectral errors, so that its eigenvectors are exactly correct?". GST can more or less directly estimate each gate's spectrum, because that's gauge-invariant. But gate eigenbases are relational to other gates and gauge-variant. To infer them, GST basically does precise spectrum estimation on germs that incorporate multiple gates. Each germ's estimated spectrum is shown elsewhere. This table compares each germ's estimated spectrum to the spectrum it would have if each individual gate had the eigenvalues that GST estimated for it, but exactly the right (target) eigenbasis. This is the "eigenspace-projected" estimate of that gate. Comparing the estimated germ spectra with those predicted by the eigenspace-projected gates yields gauge-invariant metrics of how much of the overall error can be attributed to purely spectral errors in each gate. If the estimated-gate eigenvalues account for everything, all of the discrepancy values in this table would equal zero.
Gate or Germ
Eigenvalue 1/2 Diamond-Dist
Eigenvalue Non-U. 1/2 Diamond-Dist
[]
0
0
Gxpi2:0
0
0
Gypi2:0
0
0
Qubit 0 ---|Gxpi2|-|Gypi2|---
0.000395
0.00014
Qubit 0 ---|Gxpi2|-|Gxpi2|-|Gypi2|---
0.001572
0.00145
Gate or Germ
Eigenvalue 1/2 Diamond-Dist
Eigenvalue Non-U. 1/2 Diamond-Dist
[]
0
0
Gxpi2:0
0
0
Gypi2:0
0
0
Qubit 0 ---|Gxpi2|-|Gypi2|---
0.00046
0.000001
Qubit 0 ---|Gxpi2|-|Gxpi2|-|Gypi2|---
0.000137
0.000018
Gate or Germ
Eigenvalue 1/2 Diamond-Dist
Eigenvalue Non-U. 1/2 Diamond-Dist
[]
0
0
Gxpi2:0
0
0
Gypi2:0
0
0
Qubit 0 ---|Gxpi2|-|Gypi2|---
0
0
Qubit 0 ---|Gxpi2|-|Gxpi2|-|Gypi2|---
0
0
Eigenvalues of estimated germs.GST directly estimates each gate's spectrum (it's gauge-invariant), But the gates' eigenbases are relational to other gates and gauge-variant. GST infers them from the spectra of germs that incorporate multiple gates. Each germ's spectrum is gauge-invariant and directly estimatable, and this table lists them. It also lists metrics that compare these spectra to the ones predicted by the eigenspace-projected gates (see elsewhere on this tab). If the individual gates' eigenvalues account for all imperfections, then the estimated and predicted germ spectra should be equal. Since spectra aren't ordered, the eigenvalues need to be matched up or aligned somehow. PyGSTi does this by identifying a minimum-weight matching based on the metric being computed. Mathematical descriptions of the metrics appear when hovering over the column headers.
This tab provides a variety of common (and uncommon) error metrics derived from the estimated gate set. All of these quanties are gauge-dependent, which means two things. First, they aren't directly physically measurable, so they can't map directly to observable error rates. Second, they are only as reliable (as diagnostics) inasmuch as pyGSTi is able to pick a sensible gauge (reference frame) in which to report gates. PyGSTi does this by first finding an estimate based on the data (and ignoring gauge entirely), then varying over all possible representations of those gates (gauges) to minimize a measure of the gates' implausibility (distance from the targets, combined with violation of positivity). This measure has parameters -- e.g. the weights placed on different gates -- and reports often include multiple "gauge optimizations". A dropdown menu in the sidebar allows switching between these options, and the parameters used for the currently-shown estimate are shown below it.
SPAM error metrics This table presents (gauge-variant) metrics that quantify errors in the SPAM operations -- the estimated initial state preparation[s] and POVM measurement -- with respect to the ideal target operations, A description of each metric can be found by hovering the pointer over the column header.
Prep/POVM
Infidelity
1/2 Trace Distance
1/2 Diamond-Dist
ρ0
-0.145056
0.150545
--
Mdefault
0.771248
0.77118
--
Prep/POVM
Infidelity
1/2 Trace Distance
1/2 Diamond-Dist
ρ0
0.851835
0.858055
--
Mdefault
0.047214
0.156235
--
Prep/POVM
Infidelity
1/2 Trace Distance
1/2 Diamond-Dist
ρ0
0
0
--
Mdefault
0
0
--
Individual gate error metricsThis table presents various (gauge-variant) metrics that quantify errors in each individual estimated logic gate, with respect to the ideal target gates. Note that "Entanglement infidelity" and "Average gate infidelity" are two common definitions of process fidelity, and related by a constant dimensional factor. A description of each metric can be found by hovering the pointer over the column header.
Gate
Entanglement Infidelity
Avg. Gate Infidelity
1/2 Trace Distance
1/2 Diamond-Dist
Non-unitary Ent. Infidelity
Non-unitary Avg. Gate Infidelity
[]
-0.000179
-0.00012
0.000767
--
-0.00018
-0.00012
Gxpi2:0
-0.000255
-0.00017
0.045137
--
-0.000291
-0.000194
Gypi2:0
-0.00026
-0.000174
0.046994
--
-0.00032
-0.000213
Gate
Entanglement Infidelity
Avg. Gate Infidelity
1/2 Trace Distance
1/2 Diamond-Dist
Non-unitary Ent. Infidelity
Non-unitary Avg. Gate Infidelity
[]
0.000144
0.000096
0.00046
--
0.000144
0.000096
Gxpi2:0
5×10-8
3×10-8
0.000213
--
0
0
Gypi2:0
0.000184
0.000123
0.00046
--
0.000184
0.000123
Gate
Entanglement Infidelity
Avg. Gate Infidelity
1/2 Trace Distance
1/2 Diamond-Dist
Non-unitary Ent. Infidelity
Non-unitary Avg. Gate Infidelity
[]
0
0
0
--
0
0
Gxpi2:0
0
0
0
--
0
0
Gypi2:0
0
0
0
--
0
0
Single metric comparison.TODO: caption
Entanglement Infidelity
Gate
TP
CPTP
Target
[]
-0.000179
0.000144
0
Gxpi2:0
-0.000255
5×10-8
0
Gypi2:0
-0.00026
0.000184
0
Avg. Gate Infidelity
Gate
TP
CPTP
Target
[]
-0.00012
0.000096
0
Gxpi2:0
-0.00017
3×10-8
0
Gypi2:0
-0.000174
0.000123
0
1/2 Trace Distance
Gate
TP
CPTP
Target
[]
0.000767
0.00046
0
Gxpi2:0
0.045137
0.000213
0
Gypi2:0
0.046994
0.00046
0
1/2 Diamond-Dist
Gate
TP
CPTP
Target
[]
--
--
--
Gxpi2:0
--
--
--
Gypi2:0
--
--
--
Non-unitary Ent. Infidelity
Gate
TP
CPTP
Target
[]
-0.00018
0.000144
0
Gxpi2:0
-0.000291
0
0
Gypi2:0
-0.00032
0.000184
0
Non-unitary Avg. Gate Infidelity
Gate
TP
CPTP
Target
[]
-0.00012
0.000096
0
Gxpi2:0
-0.000194
0
0
Gypi2:0
-0.000213
0.000123
0
Frobenius Distance
Gate
TP
CPTP
Target
[]
0.001675
0.001185
0
Gxpi2:0
0.091062
0.000603
0
Gypi2:0
0.095345
0.001145
0
Per-germ error metricsThis table presents various (gauge-variant) metrics that quantify errors in the estimated germs, with respect to their ideal target counterparts (as computed from the ideal target gates). A description of each metric can be found by hovering the pointer over the column header..
Gate or Germ
Entanglement Infidelity
1/2 Trace Distance
Non-unitary Ent. Infidelity
[]
-0.000179
0.000767
-0.00018
Gxpi2:0
-0.000255
0.045137
-0.000291
Gypi2:0
-0.00026
0.046994
-0.00032
Qubit 0 ---|Gxpi2|-|Gypi2|---
-0.00044
0.051846
-0.000461
Qubit 0 ---|Gxpi2|-|Gxpi2|-|Gypi2|---
-0.000647
0.056596
-0.000656
Gate or Germ
Entanglement Infidelity
1/2 Trace Distance
Non-unitary Ent. Infidelity
[]
0.000144
0.00046
0.000144
Gxpi2:0
5×10-8
0.000213
0
Gypi2:0
0.000184
0.00046
0.000184
Qubit 0 ---|Gxpi2|-|Gypi2|---
0.000184
0.000415
0.000184
Qubit 0 ---|Gxpi2|-|Gxpi2|-|Gypi2|---
0.000184
0.000589
0.000184
Gate or Germ
Entanglement Infidelity
1/2 Trace Distance
Non-unitary Ent. Infidelity
[]
0
0
0
Gxpi2:0
0
0
0
Gypi2:0
0
0
0
Qubit 0 ---|Gxpi2|-|Gypi2|---
0
0
0
Qubit 0 ---|Gxpi2|-|Gxpi2|-|Gypi2|---
0
0
0
Raw Estimates
This tab shows the raw GST estimates — the density matrices, POVM effects, and process matrices that comprise the estimated gateset. These are explicitly gauge-dependent, and most reports include multiple gauge optimizations that correspond to slightly different (but physically equivalent and indistinguishable) representations of the operations. Usually, these raw estimates are less useful than the derived properties and decompositions shown elsewhere, but sometimes it's useful to see them. Furthermore, it's possible (at least in some versions of the report) to download the raw gateset in machine-readable form, in order to do calculations and simulations with it.
Estimated SPAM operationsThis table presents the GST-estimated SPAM operations — the initial state, as a density matrix, and the terminating measurement as a POVM — and compares them to the corresponding ideal target operations. All of these matrices should be positive semidefinite, so their eigenvalues are shown to provide a quick diagnostic.
Estimated logic gate operationsThis table presents the GST-estimated logic gates — represented as process matrices (aka Liouville superoperators or Pauli transfer matrices) — and compares them to the ideal (generally unitary) target logic gates. Each gate is represented as a d^2\times d^2superoperator that acts by matrix multiplication on vectors in the vector space \mathcal{B}(\mathcal{H}) of operators. Matrices are displayed using a heat map that ranges between 1.0 (red) and -1.0 (blue), and hovering the pointer over a matrix element will pop up its precise numerical value. Note that it is impossible to discern even order-1%% deviations from the ideal in this view; that's what other analyses (especially the Gate Error Generators tab) are for.
This tab presents several decompositions of the process matrices shown on the Raw Estimates tab. These are derived properties of the process matrices that aren't directly interpretable as error metrics, but help understand both the overall observed/estimated behavior of the gates and how they differ from the targets. Although the tables on this page do not compare the estimated gates' properties directly to those of the ideal targets, many reports include an analysis of the target gates as well, which can be accessed (and compared directly to the GST estimates) through the Estimates dropdown menu on the sidebar. Also, since these properties are all at least mildly gauge-dependent, it may be useful to examine different gauge-optimization choices using that dropdown menu on the sidebar.
Decomposition of estimated gates.This table attempts to describe each gate as a rotation operator (this interpretation is more reliable for single qubits than for other systems). From each gate, a rotation axis and angle are extracted by considering the projection of its logarithm onto the Pauli Hamiltonian projectors. The rotation axis and angle are (respectively) given by the direction and the magnitude (up to a conventional constant) of this projected logarithm. In other words, the rotation axis is basically the Hamiltonian that generated the gate. The angles between the various gates' rotation axes are computed from the dot products between them.
Estimated gates' Choi representation and spectra These plots show each gate's Choi-Jamiolkowski representation and that representation's eigenvalues. Every completely positive (CP) map has a non-negative Choi spectrum, so any negative eigenvalues (shown in red) indicate that the estimate violates positivity. If a gate is perfectly unitary, its Choi spectrum will be rank-1, and real-world gates often have many Choi eigenvalues that are very close to zero. Therefore, although negative eigenvalues indicate that the estimate is non-physical, this can easily stem from statistical fluctuations. If statistically significant, though, it usually indicates either non-Markovianity or a failed gauge optimization. Since the Choi matrix is Hermitian, it is displayed using colored boxes by placing the real and imaginary parts of the upper-triangle's off-diagonal elements in the upper and lower triangles of the color box plot, respectively.
Gate
Choi matrix (Pauli-Product basis basis)
Eigenvalue Magnitudes
[]
Gxpi2:0
Gypi2:0
Gate
Choi matrix (Pauli-Product basis basis)
Eigenvalue Magnitudes
[]
Gxpi2:0
Gypi2:0
Gate
Choi matrix (Pauli-Product basis basis)
Eigenvalue Magnitudes
[]
Gxpi2:0
Gypi2:0
Gate Error Generators
This tab presents the error generators for each of the estimated gates. Although these are not especially well-known in the literature, they are (in the pyGSTi authors' opinion) the most useful detailed diagnostic for gate errors. The error generator \mathbb{L} for a noisy gate G with ideal target G_0 is defined by writing
G = e^{\mathbb{L}} G_0
. It can be thought of, more or less, as a Lindbladian superoperator that generates the error in the gate — with two caveats. First, it is not necessarily of strict Lindblad form, because the GST-estimated gates may not be CP, and because even if they are, not every CP map is "divisible" (and nondivisible maps are not generated by Lindblad evolution). Second, the generator reported here is a
post-gate generator, so it answers the question "If all the noise occurred after the ideal gate, what Lindbladian would generate it?"
Finally: the error generators are very definitely gauge-dependent, so caveat emptor (cross-validating any inferences drawn from these generators with some sort of gauge-invariant diagnostic is highly recommended).
Logic gate error generators The first column displays a heat map of the estimated error generator for each gate. This is (more or less) the Lindbladian \mathbb{L} that describes how the gate is failing to match the target. This error generator is defined by the equation
G = e^{\mathbb{L}} G_0
. If it is zero, the estimated gate matches the corresponding ideal target gate. Note that the range of the colorscale is dynamically adjusted. Subsequent columns show the result of projecting each generator onto some subspaces of the error generator space. Each corresponds to a different classes of well-known errors: Hamiltonian (coherent) errors, Pauli-stochastic errors, and affine (aka non-unital) errors. The Hamiltonian generators act by commutation with each Pauli basis element B_i, that is \rho \rightarrow -i[B_i, \rho]. Stochastic generators act by conjugation with each basis element, \rho \rightarrow B_i \rho B_i^\dagger. Affine generators act by projecting everything onto a particular basis element, \rho \rightarrow \mathrm{Tr}(\rho) B_i. Roughly speaking, the Hamiltonian projection corresponds precisely to the Hamiltonian that would produce the coherent part of the error, while the Pauli-stochastic generators correspond to the rates of all the Pauli errors (e.g., X errors, Z errors, their 2-qubit counterparts, or whatever is appropriate for the system being analyzed).
Gate
Error Generator
Pauli Hamiltonian Projections
Pauli Stochastic Projections
Pauli Affine Projections
[]
Gxpi2:0
Gypi2:0
Gate
Error Generator
Pauli Hamiltonian Projections
Pauli Stochastic Projections
Pauli Affine Projections
[]
Gxpi2:0
Gypi2:0
Gate
Error Generator
Pauli Hamiltonian Projections
Pauli Stochastic Projections
Pauli Affine Projections
[]
Gxpi2:0
Gypi2:0
Input Summary
This tab presents a grab bag of potentially-useful information about the target gate set and the data set(s).
Ideal SPAM operations The idealtarget state preparations (\rho_i) and POVM effects E_i for the device analyzed in this report. SPAM (state preparation and measurement) operations are given as d\times d matrices in the standard (matrix unit) basis of Hilbert space.
Operator
Matrix
Eigenvals
ρ0
$ \begin{pmatrix}
1 \\
0
\end{pmatrix} $
0
$ \begin{pmatrix}
1 \\
0
\end{pmatrix} $
1
$ \begin{pmatrix}
0 \\
1
\end{pmatrix} $
Fiducial circuits A list of the preparation and measurement fiducial circuits. These circuits precede and follow, respectively, the potentially long germ-to-some-power portion of GST gate sequences, and generate informationally complete input/output ensembles from the native state preparation[s] and measurement.
Fiducials
#
Prep.
Measure
1
2
Gxpi2:0
Gxpi2:0
3
Gypi2:0
Gypi2:0
4
Gxpi2:0.Gxpi2:0
Gxpi2:0.Gxpi2:0
5
Gxpi2:0.Gxpi2:0.Gxpi2:0
Gxpi2:0.Gxpi2:0.Gxpi2:0
6
Gypi2:0.Gypi2:0.Gypi2:0
Gypi2:0.Gypi2:0.Gypi2:0
Germs A list of the germ circuits used in this experiment. Germs are relatively short circuits that get repeated (perhaps many times) in order to amplify various types of qubit errors. The list of germs is often chosen so that all possible types of in-model errors are amplified by at least one germ. Note: it's generally impossible to find a single germ that amplifies all possible errors, except when the gate being studied is the identity operation.
#
Germ
#
Germ
1
4
Gypi2:0
2
[]
5
Gxpi2:0.Gypi2:0
3
Gxpi2:0
6
Gxpi2:0.Gxpi2:0.Gypi2:0
Dataset properties This table lists various properties of the data set used in the analysis. It is useful for sanity checks.
Quantity
Value
Number of strings
784
Gate labels
Gxpi2:0, Gypi2:0
Outcome labels
('0',), ('1',)
Counts per string
1024
User comment 1
Ideal logic gates The idealtarget (generally unitary) logic gates. Each has a name starting with G, and is represented as a d^2\times d^2superoperator that acts by matrix multiplication on vectors in \mathcal{B}(\mathcal{H}). Matrices are displayed using a heat map that ranges between 1.0 (red) and -1.0 (blue).
Gate
Superoperator (Pauli-Product basis basis)
[]
Gxpi2:0
Gypi2:0
System and pyGSTi parameters
This tab contains a raw dump of system information and various pyGSTi parameters. Its purpose is to stamp this report with parameters that indicate how exactly GST was run to create it, as well as to record the software environment in within which the report creation was run. However, if the core GST computation was done on a different computer, then the software information contained here will be less useful (it describes the environment in which the report was generated, not the one in which the estimate was generated).
Listing of GST parameters and meta-data. These parameters and related metadata describe how the GST computation that produced this report was performed.
Quantity
Value
check
False
contractStartToCPTP
False
cptpPenaltyFactor
0
depolarizeStart
0
distributeMethod
default
includeLGST
True
max length list
[1, 2, 4, 8, 16, 32]
maxIterations
100000
memLimit
None
minProbClip
0.0001
minProbClipForWeighting
0.0001
nestedCircuitLists
True
objective
logl
opLabelAliases
None
probClipInterval
(-1000000.0, 1000000.0)
profile
1
radius
0.0001
randomizeStart
0
spamPenaltyFactor
0
starting point
LGST
tolerance
1e-06
truncScheme
whole germ powers
useFreqWeightedChiSq
False
Quantity
Value
check
False
contractStartToCPTP
False
cptpPenaltyFactor
0
depolarizeStart
0
distributeMethod
default
includeLGST
True
max length list
[1, 2, 4, 8, 16, 32]
maxIterations
100000
memLimit
None
minProbClip
0.0001
minProbClipForWeighting
0.0001
nestedCircuitLists
True
objective
logl
opLabelAliases
None
probClipInterval
(-1000000.0, 1000000.0)
profile
1
radius
0.0001
randomizeStart
0
spamPenaltyFactor
0
starting point
User-supplied-Model
tolerance
1e-06
truncScheme
whole germ powers
useFreqWeightedChiSq
False
Quantity
Value
max length list
[1, 2, 4, 8, 16, 32]
minProbClip
0.0001
objective
logl
opLabelAliases
None
radius
0.0001
truncScheme
whole germ powers
Profiler timing. Timing information from pyGSTi's built-in lightweight profiler (if it was enabled).
Label
Time (sec)
do_iterative_mlgst: total time
2.8850009441375732
do_long_sequence_gst: total long-seq. opt.
2.8850009441375732
do_mc2gst: total time
2.212066888809204
do_mc2gst: leastsq
1.036085844039917
do_mc2gst: pre-opt treegen
0.8140032291412354
do_iterative_mlgst: iter 6 chi2-opt
0.7650353908538818
bulk_fill_dprobs: total
0.7439796924591064
do_mc2gst: JACOBIAN
0.6370155811309814
compute_dproduct_cache: serial
0.531052827835083
bulk_fill_dprobs: compute_dproduct_cache
0.531052827835083
do_iterative_mlgst: iter 4 chi2-opt
0.490001916885376
do_iterative_mlgst: iter 5 chi2-opt
0.48399949073791504
compute_dproduct_cache: dots
0.41901326179504395
GateSetTomography: add badfit estimates
0.4054083824157715
do_long_sequence_gst: Starting Point (LGST)
0.3039991855621338
do_mlgst: total time
0.2919962406158447
do_iterative_mlgst: iter 6 logl-opt
0.2919962406158447
do_mc2gst: OBJECTIVE
0.20403242111206055
GateSetTomography: gauge optimization
0.19922208786010742
do_iterative_mlgst: iter 3 chi2-opt
0.19303369522094727
do_mlgst: post-opt
0.15901398658752441
do_iterative_mlgst: iter 2 chi2-opt
0.1419994831085205
do_iterative_mlgst: iter 1 chi2-opt
0.1399996280670166
bulk_fill_dprobs: calc_and_fill
0.1359398365020752
do_mlgst: pre-opt
0.1329822540283203
do_iterative_mlgst: iter 6 logl-comp
0.12998175621032715
do_mlgst: JACOBIAN
0.12700223922729492
do_iterative_mlgst: iter 5 logl-comp
0.08799958229064941
do_iterative_mlgst: iter 4 logl-comp
0.08600068092346191
bulk_fill_dprobs: compute_product_cache
0.06898903846740723
do_iterative_mlgst: iter 3 logl-comp
0.03796267509460449
do_mlgst: OBJECTIVE
0.028016090393066406
do_iterative_mlgst: iter 2 logl-comp
0.023001909255981445
do_iterative_mlgst: iter 1 logl-comp
0.013000965118408203
custom_leastsq: dotprods
0.009992837905883789
custom_leastsq: linsolve
0.009000062942504883
GateSetTomography: results initialization
0.00599980354309082
do_long_sequence_gst: loading
0.0
do_long_sequence_gst: Prep Initial seed
0.0
do_mc2gst: num data params
0.0
MPI IPC
0.0
do_mlgst: num data params
0.0
Label
Time (sec)
do_long_sequence_gst: total long-seq. opt.
22.191999197006226
do_iterative_mlgst: total time
22.183997631072998
do_mc2gst: total time
20.847994327545166
do_mc2gst: leastsq
20.29098868370056
do_mc2gst: JACOBIAN
13.440275430679321
do_iterative_mlgst: iter 1 chi2-opt
12.554996728897095
bulk_fill_dprobs: total
11.128702640533447
bulk_fill_dprobs: compute_dproduct_cache
7.264303684234619
compute_dproduct_cache: serial
7.260306119918823
do_mc2gst: OBJECTIVE
5.290766954421997
compute_dproduct_cache: dots
4.610808610916138
do_iterative_mlgst: iter 6 chi2-opt
3.288996458053589
bulk_fill_dprobs: calc_and_fill
3.0621092319488525
do_iterative_mlgst: iter 4 chi2-opt
2.102975368499756
do_iterative_mlgst: iter 5 chi2-opt
1.687002420425415
GateSetTomography: add badfit estimates
1.0339996814727783
do_mlgst: total time
0.9439985752105713
do_iterative_mlgst: iter 6 logl-opt
0.9439985752105713
do_mc2gst: pre-opt treegen
0.935997486114502
GateSetTomography: gauge optimization
0.8360030651092529
do_mlgst: post-opt
0.813960075378418
do_iterative_mlgst: iter 3 chi2-opt
0.7149658203125
do_mlgst: JACOBIAN
0.654944658279419
bulk_fill_dprobs: compute_product_cache
0.5982997417449951
do_iterative_mlgst: iter 2 chi2-opt
0.5020351409912109
custom_leastsq: linsolve
0.2389967441558838
custom_leastsq: dotprods
0.1802992820739746
do_iterative_mlgst: iter 6 logl-comp
0.14200115203857422
do_mlgst: OBJECTIVE
0.14098739624023438
do_mlgst: pre-opt
0.13003849983215332
do_iterative_mlgst: iter 5 logl-comp
0.11500096321105957
do_iterative_mlgst: iter 4 logl-comp
0.06299972534179688
do_iterative_mlgst: iter 3 logl-comp
0.03602409362792969
do_iterative_mlgst: iter 2 logl-comp
0.021000146865844727
do_iterative_mlgst: iter 1 logl-comp
0.011001348495483398
GateSetTomography: results initialization
0.005002498626708984
MPI IPC
0.0019991397857666016
do_long_sequence_gst: loading
0.0
do_long_sequence_gst: Starting Point (User-supplied-Model)
0.0
do_long_sequence_gst: Prep Initial seed
0.0
do_mc2gst: num data params
0.0
do_mlgst: num data params
0.0
Label
Time (sec)
ModelTest: add badfit estimates
0.8229987621307373
ModelTest: results initialization
0.009000539779663086
ModelTest: gauge optimization
0.0009992122650146484
Standard output. The standard output text, along with warnings and errors, that was collected (recorded) when GST was run to create the results reported here.
Listing of the software environment. This table describes the software environment of the machine used to generate this report. It may not describe the machine used to perform the core GST gate set estimation.
Quantity
Value
pyGSTi version
0.9.9.3
numpy
1.18.4
scipy
1.4.1
matplotlib
3.2.1
ply
3.11
cvxopt
missing
cvxpy
missing
nose
missing
PIL
7.1.2
psutil
5.7.0
Python version
3.7.0
Python type
CPython
Python compiler
MSC v.1914 64 bit (AMD64)
Python build
('v3.7.0:1bf9cc5093', 'Jun 27 2018 04:59:51')
Python branch
v3.7.0
Python revision
1bf9cc5093
Platform summary
Windows-10-10.0.19041-SP0
System
Windows
Sys Release
10
Sys Version
10.0.19041
Machine
AMD64
Processor
Intel64 Family 6 Model 158 Stepping 10, GenuineIntel
How to use this report
Welcome to a pyGSTi report! This HTML document provides an interactive view onto a lot of information about one or more gateset tomography (GST) experiments that were analyzed using the pyGSTi software. This Help tab should help you use this report's interactive features, figure out where to find things, and access the context-sensitive help features embedded throughout the report.
Background
PyGSTi's primary purpose is to ingest GST datasets and find a good estimate of the gateset that generated that data. But pyGSTi can also produce a lot of detailed analyses and visualizations of the estimates that it generates. That's what you'll find in this report. You can inspect the raw estimated gateset too, but if you want to do your own calculations with it — e.g., to simulate experiments or calculate interesting quantities that the pyGSTi authors haven't thought of — then the best way to do that is by using pyGSTi itself in a Jupyter or iPython notebook.
This report's structure
PyGSTi uses HTML for reporting because it's pretty portable and supports interactivity. Interactivity makes it possible to embed a lot of different perspectives and analyses, without overwhelming you with too much information at once or requiring you to scroll through long static (e.g. PDF) documents. In this report, actual content is displayed in the main panel, while navigation tools that let you decide what content to examine are collected in a sidebar on the left. The tables and figures in the main panel are also somewhat interactive (see “Interacting with content” below). Most of them dynamically change what they show depending on the positions of one or more switches - dropdown-menus, button-sets, or sliders. Most switches are located on the sidebar, but some appear in the main panel beneath the figure or table that they control. Note that some content is generated on the fly, so there may be a lag the very first time you view a given tab, while your browser makes plots or renders math formulas.
Choosing what to see via the sidebar
The sidebar provides two distinct ways to control what you see. First, the data analysis is broken up into different tabs that are listed on the sidebar. Use the sidebar to hop between them. Each tab collects a particular category of analysis, presented as tables and figures. Second, if the report contains multiple analyses, the sidebar displays switches that allow you to pick which analysis to display in the main panel. A report can contain: (1) multiple distinct datasets; (2) the results of different estimators (each associated with a given dataset); and (3) multiple distinct but equivalent representations (gauges) for each estimate. You can choose between these options using the drop down menus labeled Dataset and Estimate, and the Gauge-Opt. button group at the bottom of the sidebar. If a switch is missing, the report doesn't contain multiple options of that type. You can hide the sidebar (or make is sticky) by clicking the ⊛ symbol in its upper right corner.
Due to the large amount of data a report can contain, there are options that allow one to omit some of the (usually larger or more data-dense) figures from the report at its creation time. This will result in the report having fewer tabs in the sidebar and/or the word OMITTED being displayed instead of a figure. To see missing tabs or omitted figures, you should ask whoever generated this report to re-generate it with a lower brevity setting.
Interacting with content
Each tab presents a (hopefully manageable) amount of content arranged into objects — figures and tables — that have some interactive properties. Here are some general tips and rules.
Resizing: Each object can be resized by dragging its lower right corner.
Zooming: You can zoom in on plots' axes by clicking and dragging within the figure. Double-clicking, or tapping the house icon that pops up in the upper right when the pointer is over a figure, will reset the axes.
Exporting: Plots can be saved in PNG format by tapping the camera icon, which only appears when the pointer is over a plot). (User beware: this is a builtin feature of the Plotly library, and we find that sometimes the saved PNG does not look like the original plot, especially in aspect ratio.) Depending on what options were selected when the report was constructed, there may also be links to download plots and tables as PDF, Python pickle files, and/or LaTeX (tables only). Plots will have additional download icons next to the camera icon, and tables will have PDF, PKL, and/or TEX links beneath them. PKL files downloaded from plots contain a pickled dictionary of the plotted data, while those downloaded from tables contain a pickled Pandas DataFrame object.
Full descriptive captions for figures and tables can be revealed by clicking on the object's Figure XX or Table XX title.
Hovering over a colored bar or box will often reveal a tool tip showing the exact number that bar or box represents. Hovering over table headings will bring up descriptive text. In the plots that show per-sequence model violation, hovering over any data point will bring up fairly extensive details about the datum that generated it.
Clickable pigs: If you see the pyGSTi logo, it's a placeholder for a plot that wasn't automatically generated (usually because this might take a little while); click on the logo to generate the plot.
The example table below demonstrates some of this functionality.
Click this title to see my full caption.This is an example table which demonstrates some of the functionality found in the other tables and figures of this report. Hovering over the column headers displays descriptive tooltips, and clicking on the pyGSTi logo will cause a plot to be generated. Hovering over the colored boxes of the plot will display the value of that box, potentially with additional information (in this case, error bars). Math formulas like \sqrt{x^2 + y^2} = \frac{1}{4} can be displayed in captions but not in tooltips, so sometimes the column-header tooltips simply refer to material in the captions.
Hover over me...
And me!
Click the pig
Pi
3.141593
Quick guide to Datasets, Estimates, and Gauge Optimizations
The single biggest change from the old PDF report format is the ability to report simultaneously on — and compare — multiple gateset estimates. This report may contain an unlimited number of distinct gatesets. Although they're often all derived from the same dataset, they may not be. For example, a single report could contain:
datasets from separate GST experiments on each qubit on a chip;
datasets from two identical GST experiments done at different times;
datasets from GST experiments on the same system, but with gate implementations;
a 2-qubit GST dataset together with 1-qubit GST datasets extracted from it;
many other possibilities.
The sidebar's Dataset dropdown menu (if present) lets you select a dataset. Then, the Estimate dropdown (if present) will list all the different estimates that are available for any of the datasets in the report. If you choose an estimate that was not generated for the current dataset (but is listed because it was generated for another dataset), unavailable plots and figures will turn into big "N/A" labels. Different estimates are usually generated by different statistical estimators. PyGSTi usually provides maximum likelihood estimates (although others are certainly possible!), but it can do MLE with no constraints at all (Full), or constrained to trace-preserving maps (TP), or constrained to completely positive maps (CPTP). Some reports include separate *.robust variations of those estimators in which poorly-fit data were deprecated, and some reports include the target gates themselves (Target) as an option.
Finally, in order to analyze each estimated gateset, pyGSTi has to choose a representation — a gauge — for it. Since pyGSTi does this gauge-fixing internally by defining an objective function and then finding the gauge that optimizes it, the choice-of-representation is referred to as Gauge Optimization. A description of the objective function used to generate this gateset appears at the bottom of the sidebar. If the report contains multiple gauge optimizations, you can choose between them by pushing the appropriate button. Choosing a good gauge is hard, and neither pyGSTi nor its users always get it right. If something reported in the Summary or Gauge-dependent error metrics tabs looks startling or implausible, it might be due to a poorly chosen gauge. Try a different gauge-optimization choice, or cross-validate whatever you see against things from the Gauge-invariant error metrics tabs.
What to look at first (and second)
If you're new to pyGSTi reports, this is probably all a bit overwhelming. Don't panic! There's a lot of context-sensitive help, and the pyGSTi authors are always happy to answer questions like What does this mean?, or Why would I care about this? But since these reports do contain a lot of stuff, here's a get-started-quickly guide.
Start with the Summary tab. It will tell you two critical things. First, in Table 3: how close do the gates seem to be to the ideal targets that were specified? Are you doing pretty well, or all messed up for some reason? If whoever did the analysis chose to produce error bars (this can take a lot of computation), they'll appear in this table. Second, the model violation plots will tell you whether the system seems to be stable and Markovian, or not (in which case, take the metrics in Table 3 with a grain of salt). Don't forget to flip through the available datasets, estimates, and gauge-optimization choices — or at least the ones you care about — while looking at this tab.
Next, you probably want to know one of two things. Either the GST model was NOT badly violated, in which case you want to know more about the errors in the gates.. or it WAS badly violated, in which case you want to know more about what's going wrong.
If you want to know more about the errors, start with Gauge Dependent Error Metrics: Overview, then take a quick look at Raw Estimates to confirm that the process matrices look about right, and then spend some quality time with Gate Decompositions and Gate Error Generators if you want to really understand what GST thinks that each individual gate is doing. If at any point you see something weird that might be due to a bad choice of gauge (examples include wildly nonpositive SPAM operations, implausibly high diamond norm errors in gates that you strongly believe to be better than that, and significantly negative elements in the Pauli stochastic part of the error generators), try a different gauge optimization. Or, go to the Gauge-invariant error metrics tabs and try to figure out whether there's something here that confirms or denies whatever effect is bugging you (e.g., if an estimated gate has an eigenvalue bigger than 1, that will produce crazy negative probabilities, and it's not a gauge problem).
On the other hand, if there's a lot of model violation, then you probably want to understand why. The information on the error metrics tabs may or may not be useful — you should be much more cautious about drawing conclusions from them if there's a lot of model violation. To dig into model violation (aka “non-Markovianity”), start with the Model Violation: Overview tab, which will give you the numbers behind the bar chart from the Summary tab, and also show you whether longer circuits violate the GST model more. (If they do, it's probably non-Markovianity in the gates. If they don't, it's probably something nastier like bistability, slow drift in SPAM operations, or corrupted data). Next, take a deep breath and dig into the “Per-sequence detail” tab, which will show you the (quantitative) inconsistency of every individual circuit with this estimate. Interpreting these charts is a bit of an art, but clusters of red boxes usually indicate that something related to the location of the cluster was suffering drift and/or non-Markovianity.